Size Change: -20 B (0%)

Total Size: 1.75 MB

_{compressed-size-action}

@SaxonF this implements the changes to template parts as described in #59659

I notice a few inconsistent things between the "Manage all template parts" page and the template parts pages in patterns. I think we may need to

• use the path=/wp_template_part URL for template parts (the pages in patterns are using path=/patterns&categoryType=wp_template_part&categoryId=header as of now)
• add an "all" item in the template parts sidebar group, like we have for patterns
• add a filter by author in all template parts dataviews pages (like we have in the existing "manage all template parts" page)

Thoughts?

I think it helps to keep #57011 in mind here, which this PR definitely moves us towards. Some consequent considerations:

• "All patterns" should eventually include template parts.
  • Menu order could be; "All patterns", "Headers", "Footers"... all other categories.
• All views should support an author filter.
• "My patterns" potentially removed in favor of author becoming a primary filter.

With that said, I agree about adding an author filter before merging this.

I think it helps to keep #57011 in mind here

Oh, thanks for sharing, wasn't aware of that. I'm going to check and will be back.

Pushed an update that implements this design and updated the TODO.

Oh neat, I didn't mean to necessarily do that here. The original approach can work too if we want to be more iterative. No strong feelings there.

If we commit to this approach then we'll need to follow-up and think about how some other details converge such as; duplicative categories ('Header', 'Headers'), creation flows, the 'General' template part category. I'll leave a note on the original issue about that.

I'll defer to Saxon on how to proceed.

#60372 adds the author field & filter to the template parts in the Patterns page.

I looked more into this and there are a few other inconsistencies (updated PR description with full details).

The CTRL+K commands open the details pages for patterns, but we need to update the backpath: it should go back to patterns, not to template_parts/all. I'll work on this separately.

I've also got two questions:

• Actions: should we make the edit action available for parts in patterns?
• Layout: should we make the list layout available for parts in patterns?

Actions: should we make the edit action available for parts in patterns?

Yes I think so.

Layout: should we make the list layout available for parts in patterns?

Probably yes, but one to explore separately?

#60659 adds edit and viewRevision actions to parts in Patterns page.

#60667 sets the backPath for Template Parts to the Patterns page.

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: oandregal <[email protected]>
Co-authored-by: jameskoster <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

I'll revisit it when #60775 and #60689 have been merged.

Actually! I think it's best if we land this now that #60775 has been merged. #60689 is bigger and will benefit from this one.

This is ready to review/land.

This feels a little jumbled to me now. It's quite unusual to see two "All" views right next to one another this way.

I'd be tempted to hold off on this until:

1. "All template parts" and "All patterns" views can be merged into a single view.
2. We have a better name for the "General" category.

A simpler approach could be to move the template parts section above the patterns section, but keep the separation:

This would give greater prominence to important site areas (header/footer) which seems worth a try.

I'd be tempted to hold off on this...

This PR prepares the code to remove the "Manage template parts" in the other PR, so, for this one, I'd rather ship a simple approach and iterate later to see how/whether we can combine the two entities.

A simpler approach could be to move the template parts section above the patterns section, but keep the separation:

Pushed this:

This feels a little jumbled to me now.

Agreed. What's the plan for improving this? It feels a bit backwards/in limbo as-is:

The whole template parts up top feels unexpected.

We could almost leave the "Manage all template parts" navigation item at the footer (name it "Template parts >" and remove the top section. And add more filters in that existing view for header, footer, general, etc.

We could almost leave the "Manage all template parts" navigation item at the footer (name it "Template parts >" and remove the top section. And add more filters in that existing view for header, footer, general, etc.

As per #59659 the next step is to actually to remove that link/section (see #60689). The direction is to consolidate patterns&parts in a single screen.

Yup, in practical terms template parts and patterns share almost all functionality. Presenting them as two separate concepts adds a lot of complexity to the experience ("Why should I use a template part over a synced pattern?", "What is a 'general' template part?"). There's also navigation menus and templates – it's a lot of overlap.

The whole template parts up top feels unexpected.

There's been feedback around making header / footer more prominent since they're frequent touch points. I think the end goal is something more like:

Headers/Footers are just pattern categories, and details like html element/area can be inferred automatically from those categories.

We can't functionally remove template parts until a theme can provide synced patterns though, right?

It's not about functionally removing them, I don't know that it will ever be possible to do that. It's more about how they are presented, and how users interact with them.

The code may be slightly different (though ideally that converges too), but I think the UX when working with a header template part should be the same as working with a synced pattern in the "Headers" category. I don't see a lot of benefit to these being surfaced as separate concepts?

I suppose I'm not understanding the idea state of this patterns view.

What will the grid on the right look like if header template parts and patterns sit side-by-side? As a site owner, I'll see X headers, but which is mine? How do I know what the others are for, or if I'm using any of them across my site? Are those going to be filterable? I'm missing some context I think.

Do you consider #55911 a blocker for merging patterns and template parts as well?

What will the grid on the right look like if header template parts and patterns sit side-by-side?

You'd see all headers—synced (template parts) and unsynced (patterns).

I'll see X headers, but which is mine? How do I know what the others are for, or if I'm using any of them across my site? Are those going to be filterable?

You can ask these questions of the current "Header" template part category. It's already unclear which one(s) are in use and what the others are for in situations where; a theme supplies multiple header template parts, or when plugins install more, or when you've created a couple of your own.

Ideally yes, usage should be filterable/sortable, and we should probably sort by usage in the default config. But we need to begin tracking usage first (#60205).

Do you consider #55911 a blocker for merging patterns and template parts as well?

Not sure if it's a blocker – usage tracking is slightly more important imo – but yes ideally the UX around editing any theme-supplied asset (templates, template parts, and patterns) aligns.

You can ask these questions of the current "Header" template part category. It's already unclear which one(s) are in use and what the others are for in situations where; a theme supplies multiple header template parts, or when plugins install more, or when you've created a couple of your own.

Well today you know that none of those are technically your header; only what's in the "Template Parts > Header" category.

Well today you know that none of those are technically your header; only what's in the "Template Parts > Header" category.

But even now a header can exist in "Templates Parts > Header" and not be in use. There's no way of knowing which ones are "your header" at the moment, except when there's only a single header at the site.

I do see the point – if you want to edit "your header", and there's only one registered header template part, then seeing all other header patterns could be distracting. But given the previous point I'm not convinced that perpetuating separate overlapping concepts is the solution. A more data-views-centric approach would be the inclusion of a primary "in use" filter for template part categories so that anything not in use is hidden by default.

do see the point – if you want to edit "your header", and there's only one registered header template part, then seeing all other header patterns could be distracting.

It's not that it's distracting, you don't even know which is your actual header(s).

I want to think about it more, but I still question if wholesale mixing the concepts of template parts and patterns is the right approach.

I think we need to keep some sort of separation, even if the "Header" category has two grids, with "Template Parts" as the first gallery, and "Patterns" as the second below it—essentially as the alternates to choose from.

I think we need to keep some sort of separation, even if the "Header" category has two grids, with "Template Parts" as the first gallery, and "Patterns" as the second below it—essentially as the alternates to choose from.

We could potentially order by the sync-status field to achieve this now. IE show all synced header patterns (template parts) first.

Another consideration I've been thinking about is whether there should be two categories;

• "Site headers" – essentially a facsimile of the current template parts. Patterns in this category have the header icon and potentially other special rules such as always being synced.
• "Content headers" – for things like post/page headers including meta, or just patterns based on the Heading block.

Eventually, I'd love there to be wayfinders attached to template parts and patterns surfaced in the Data Views for easier discovery of:

• What is actively in use (eg. active header template part and/or patterns, or footer etc)
• Link to a filtered view of the template(s) (or pages) that have that pattern/template part.

This wayfinding can make it easier to update various aspects of a site design (especially more complex sites that have multiple landing pages and or content trees). This is likely something that could be implemented incrementally too (focus on header/footer template parts first initially).

What is actively in use (eg. active header template part and/or patterns, or footer etc)
Link to a filtered view of the template(s) (or pages) that have that pattern/template part.

These are both tracked in #60205